敏捷真正的產品是 Feedback：提早知道哪些東西不用做、哪些做錯了。Sprint 只是取得 Feedback 的節奏器。

兩個都在跑 Sprint 的團隊

昨天結尾留了一個問題：瀑布賣的是承諾，前提是「我們已經知道得夠多」。那如果我們誠實承認——現在就是不知道呢？

今天講兩個團隊的故事。它們都說自己在跑敏捷，都有兩週一輪的 Sprint。案例一樣經過去識別化與合併改寫。

第一個團隊在做一個小型內部工具，使用者是組織裡的幾十位同仁。做法很樸素：兩週出一版，每一版真的部署上去，真的有人用；下一輪 Planning 的第一件事，是看上一版被用得怎麼樣——哪個功能沒人碰、哪個地方大家在繞路、使用者又提了什麼。

三個月後，他們回頭看開工時規劃的功能清單，發現將近一半被劃掉了。不是做不完，是確定不用做：原本以為必要的批次匯入，觀察下來使用者一次只處理幾筆；原本排在清單最後的一個小功能，因為每個使用者都在手動繞路做同一件事，第三輪就被提到最前面做掉了。

第二個團隊在做一個對外的專案。Sprint 跑好跑滿：Planning、Standup、Review、Retro，儀式一場不缺。需求在開工時就規劃完了，Backlog 排得整整齊齊；每一輪從清單上拿兩週的量下來做，做完勾掉；Review 上對 PM 與主管簡報進度，大家說「沒問題，繼續」。

三個月後，功能完成過半，第一次拿給真正的使用者看。

會議記錄很長。這裡只需要知道一件事：清單上已經做完的那些，有不少要重做。

當時團隊怎麼理解敏捷

第二個團隊的自我認知，攤開來每一句都站得住：

我們有 Sprint，有固定節奏；每兩週都有可以展示的進度；Review 有開，該來的人都來了，也都說沒問題；Backlog 有維護，每張卡都有人負責；Retro 也有做，會議效率一直在進步。

哪裡不敏捷了？

問題出在一個很少被檢查的地方：這三個月裡，有沒有任何一次「做出來的東西」，改變過「接下來要做什麼」？

答案是沒有。Backlog 的順序從第一天到第三個月沒有動過。每一輪結束，清單短掉兩週的量；計畫本身，一毫米都沒有動。

第一個團隊的清單三個月改了一半；第二個團隊的清單三個月只是被消化。這就是今天要講的差別。

敏捷到底在賣什麼

瀑布賣承諾，敏捷（Agile／Adaptive）賣的也只有一個東西：

Feedback，以及據此改變方向的能力。

它的邏輯鏈，跟昨天那條剛好從相反的前提出發：

我們承認還不知道完整答案
        ↓
先做一小段——小到可以真的被使用
        ↓
拿給真實使用者，取得 Feedback
        ↓
根據 Feedback，重新決定下一步做什麼
        ↓
下一輪，重複

注意，這條鏈的第一行同樣是前提，不是步驟。承認自己不知道，後面每一輪才有存在的意義：每做一小段，就用真實世界的反應換一點答案回來。

所以敏捷最值錢的產出，常常不是「做出來的東西」，而是：

提早知道哪些東西不用做、哪些東西做錯了。

第一個團隊劃掉的那半張清單，不是損失，是產品。每一條被劃掉的項目，都是一筆省下來的開發、測試與維護——而且是在動工之前省下來的，這是最便宜的時機。

拿這條鏈回頭比對第二個團隊，會發現斷點不在儀式，儀式全都在。斷的是中間那兩環：

先做一小段
→ 有。每兩週都有產出

拿給真實使用者，取得 Feedback
→ 沒有。Review 的觀眾是 PM 與主管，
   他們確認的是「進度有沒有跑」，不是「方向有沒有對」

根據 Feedback 重新決定下一步
→ 無從發生。沒有輸入，就沒有重新決定

有 iteration，不等於有 feedback。

一個 Sprint，如果結束時沒有任何真實世界的訊息進來、沒有任何決定因此改變，它就不是敏捷的一輪，只是一個為期兩週的小瀑布——mini-waterfall。第二個團隊真正的運作方式，是把一個半年的瀑布切成十幾段，每一段都忠實繼承同一份沒被檢驗過的假設，分期執行。

切得再碎，瀑布還是瀑布。切碎只是讓它看起來很忙。

檢驗只需要一個問題：

最近一次 Feedback，改變了你們的什麼決定？

答得出來，Sprint 是回饋迴圈；答不出來，Sprint 是進度回報週期。

大神腦袋裡藏了什麼

那第二個團隊為什麼三個月都沒有人覺得不對勁？

因為缺席的 Feedback，有人在代班。

團隊裡的資深成員做過幾個類似的案子。Backlog 當初就是照他的判斷排的；Review 上主管問「使用者會不會不習慣這個操作」，是他回答的；設計拿不定主意時，是他說「上次類似的案子這樣做，對方可以接受」。

大部分時候，他是對的。這正是最麻煩的地方：因為他大部分時候是對的，所以沒有人發現，團隊其實從來沒有問過真正的使用者。

看清楚他在提供什麼。他提供的不是技術，是替代品——用他過去累積的使用者反應，代替這個專案該取得的使用者反應。

換句話說，大神的直覺是一份快取的 Feedback。

快取有兩個問題：它會過期——這次的使用者不是上次的使用者；而且它讓你以為自己不需要回源頭讀資料。第二個團隊要重做的那些功能，剛好都落在快取失效的地方。

這次到底誰在吸收代價？

老規矩。第二個團隊三個月的產出有不少要重做，這個代價記在誰的帳上？

Scope       □   規劃的一項都沒少做——這正是問題所在
Time        □   每個 Sprint 都準時結束，看板漂亮
Cost        □   沒人提追加，帳面上一直是綠的
Quality     ■   重做擠壓後期，測試又要被壓縮
Risk        □   沒人重新評估過：計畫沒變，是要評估什麼
人          ■   重做的加班，加上大神長期代班 Feedback   ← 還是這格

再看第一個團隊的帳本，同一格長得完全不一樣：

Scope       ■   將近一半被主動劃掉、順序重排——這是選擇，不是損失
人          □   沒有人需要加班補救方向

同樣面對「一開始不知道完整答案」的不確定性，第一個團隊用 Scope 的重新排序吸收，第二個團隊用品質與人吸收。

差別不在誰的工程師比較強，在於不確定性被誰接住：被機制接住，還是被人接住。

Feedback 不會讓不確定性消失，它只是讓你可以用 Scope 付帳，而不是用人付帳。

如果沒有大神，應該留下什麼

回到敏捷的賣點：Feedback。要讓它是機制而不是某個人的直覺，每一輪開始前，團隊要能一起寫出這四行：

1. 這一輪要驗證什麼假設？
   （我們猜使用者需要什麼、會怎麼用——寫出來，才有對錯可言）

2. 做出來的東西要拿給誰看？
   （真實使用者。不是主管、不是 PM、不是大神的記憶）

3. 看什麼來判斷猜對或猜錯？
   （他實際的操作與反應，不是客套的「不錯啊」）

4. 結果如何改變下一步？
   （猜錯的話，下一輪的計畫哪裡會不一樣）

第四行最重要。前三行都做了、第四行永遠是「照原計畫」，那前三行只是儀式清單上多出來的三項。

今日 Artifact｜最小回饋記錄

把四行收成今天的 Artifact，貼在每一輪 Sprint 的第一天：

□ 驗證假設：這一輪我們想確認＿＿＿＿
□ 給誰看：真實使用者是＿＿＿＿
□ 看什麼：用＿＿＿＿來判斷猜對或猜錯
□ 改變什麼：結果出來後，下一輪因此＿＿＿＿

四格都填得出來，而且最後一格真的發生過，你的 Sprint 才有資格叫做迭代；填不出來，它只是行事曆上每兩週重複一次的會議包。

今日一句

Sprint 不是敏捷的產品，它只是取得 Feedback 的節奏器；沒有 Feedback 的 Sprint，是把同一個瀑布切碎了，分期執行。

到這裡，兩邊賣的東西都上架了：瀑布賣承諾，敏捷賣回饋。聽起來壁壘分明，於是市面上流傳著一句方便的口訣：「瀑布固定 Scope、敏捷固定 Time。」

背起來很順。明天我們來看看，為什麼照著用會出事——沒有那麼簡單。